title: RFC – Внедрение работы с рисками
sticker: emoji//1f5d2-fe0f
aliases:
- RFC – Внедрение работы с рисками🗒RFC – Внедрение работы с рисками
Автор: @rokymiel Кузнецов Михаил Александрович
Получатели:
- Держатели професcии Мобильная разработка
Введение и предпосылки
Рост продукта и инфраструктуры в области мобильной разработки в нашей компании привело к значительным изменениям в процессах. Большой объем ресурсов, количество поставляемого функционала стало причиной перестроек в подходах к управлению и к организации работы в целом. Все это стало приводить к тому, что стала возникать большая область неопределенности, а также нарастать издержки. В связи с этим, помимо модернизации продуктовых подходов, а также подходов к процессу разработки в целом, требуются серьезные изменения в работе с рисками, так как эффективное управление ими является неотъемлемой частью менеджмента и так же крайне важно и для мобильной разработки.
Учитывая контекст и особенности деятельности нашей компании, в рамках данного RFC предлагается внедрение практик, изложенных в стандартах ISO 31000, а также в его российском аналоге ГОСТ Р ИСО 31000, для трансформации работы с рисками в нашей професcии "Мобильная разработка".
Обзор приминимости
Определение ситуации – среда и контекст (анализ)
Прежде чем рассматривать предлагаемый инструментарий необходимо выделить особенности, которые характерны для рассматриваемой нами области. Это необходимо, чтобы четко зафиксировать скоуп и его черты, так как именно из этого формируется неопределенность.
Для нашей области (а именно "Мобильная разработка") в текущих условиях характерно то, что на нее делается большая ставка в условиях быстро растущего рынка и освобождающихся нишь. Это в свою очередь приводит к росту клиентской базы, числу продуктов и высокой конкуренции, что требует особенно относится к качеству и срокам поставок. Особенность рынка такова, что выросло множество различных бизнесов, а кадровый резерв не изменился. То есть наблюдается явный дефицит качественного трудового ресурса в области. Кроме того – санкции. Они мешают публикации продукта на международных площадках. Инструменты обхода ограничений известны, но они все дают лишь малую гарантию собственной эффективности, что явно необходимо учитывать в процессе разработки.
Учитывая все вышеперечисленное, мы приходим к выводу, что в текущем контексте нельзя продолжать использовать текущие подходы, которые сейчас приводят к задержке сроков, неопределенностям как в самом процессе, так и в результате в целом. Ожидания заказчиков стали расходиться с реальностью. Поэтому требуется качественная работа с рисками, которая будет вплетена в процесс разработки в целом.
Методоллогия
В основу работы над рисками должно войти создание плана управления рисками, а также создания единой базы по продуктам и по профессии в частности. Необходимо выделять центр по работе с рисками, учитывая версионирование и зоны влияния (продукт/профессия и тд). Все это предлагается исходя не только из специфики ситуации, но и из особенностей новых процессов и подходов.
В основе работы всех наших команд – продуктовый, гибкий подход. Любой ЖЦ подразумевает стадию планирования, а адаптация к изменениям необходима для конкуренции и качества продукта. Поэтому в работе с рисками нам нужно придерживаться того же – итеративности, непрерывности. А в центре поставить планирование.
Таким образом мы приходим к тому, что работа с рисками будет основываться на наших текущих Agile подходах (анализ -> планирование -> разработка -> проверка -> анализ -> ...). Но в работе с рисками мы по сути будем работать не только с одной "желаемой" веткой исхода событий, а мы как-бы будем просчитывать все возможные ответвления. То есть при работе с рисками мы делаем все то же самое, что и в гибких процессах разработки, но берем область шире – смотрим на весь скоуп исходящих вероятностей и управляем ими.
Реализация
То есть основным инструментом становится – план управления рисками. А для его внедрения мы используем все то, что используется в нашей сфере, а именно
- Общая база рисков (аналог проблем (issue) в Jira)
- Регулярные встречи
- Grooming – аналогично изучению бэклога нужно изучать и реестр рисков
- Planning – отслеживание текущего статуса реестра, оценка риска
- Автоматизация по работе с реестром – уведомления, проверка статусов и тп
Работа с рисками
Идентификация и оценка риска
Стартом, как и для любой задачи, так и для риска становится – идентификация (как поиск проблемы в продуктовой задаче). Чтобы выявить и оценить риски, в первую очередь возьмем за основу факторы, описанные в 6.4.2 ГОСТ Р ИСО 31000. Таким образом мы можем, как и в продуктовых задачах, сначала взять такие методы как: брейншторминг, анализа существующих сценариев, сбор аналитики, общение с экспертами. И по итогу выявления всех возможных рисков – производить (по аналогии с багами) записи в реестр. После же производить уже оценку, классификацию и иную детализацию. Это необходимо даже для ситуаций, которые не будут являться риском вовсе. Хранение записей в реестре поможет производить поиск и аналитику по всей истории таких вероятностных событий и актуализировать их.
При заполнении информации о риске нужно вносить информацию в соответсвии с факторами 6.4.2 ГОСТ Р ИСО 31000. После же этого производить анализ самого риска.
Такой подход позволит гибко и автоматизированно производить оценку, так как все данные будут сверяться с общими установленными критериями риска.
Обработка риска
После создания задачи происходит ее спецификация – определение работ, ответственных и тд. В случае с рисками мы сохраним этот процесс. После оценки риска необходима описать, как именно реагировать на риск – то есть обрабатывать. Необходимо заносить в реестр для риска возможные стратегии реагирования с закреплением ответственных лиц. Здесь так же важно версионирование, так как мы сможем благодаря этому изменять варианты обработки рисков в зависимости от анализа новой ситуации
Итеративность и гибкость
Как было указано ранее – в основе те же подходы, которые мы будем использовать в разработке в целом. То есть главное – итеративность, непрерывность и гибкость. Поэтому требуются определенные мероприятия по обработке создаваемого реестра рисков, так как идентификации и формулирования обработки риска не достаточно
Мониторинг
Так как для нас важна непрерывность и итеративность, весь процесс менеджмента рисков должен быть пронизан регулярной работой по контролю и пересмотру реестра. Для этого важным становится мониторинг, который возможно реализовать благодаря регулярным встречам команды и связанных лиц, а также автоматизациям.
Встречи – коллективное обсуждение в заранее заданном формате (планирование по SCRUM, grooming или же любой другой). Но самым главным тут должно стать наличие ведущего, который не только модерирует встречу, но и следит за принятыми решениями и актуализирует информацию в реестре
Автоматизация – инструмент фонового отслеживания статуса из реестра, чтобы до плановых встреч получать регулярную сводку по текущему состоянию рисков. А при наличии очного формата работы можно использовать стэнды с дашбордами, где можно отслеживать особо важные риски.
Мониторинг должен быть частью всех процессов в команде. А его результаты должны быть частью системы измерения эффективности деятельности, а также отчетности команды.
Оценка
Возвращаясь к гибким методологиям, мы выделим еще один важный этап – оценка. Как и в случае с Agile, нам крайне важно регулярно производить оценку всего процесса, чтобы выявлять узкие места и точки роста. Точно такие же подходы приминимы и важны при работе с рисками. Соответсвенно оценку эффективности, связанную с рисками, нужно сделать частью всей системы анализа работы команды. Таким образом это автоматически станет регулярным и будет синхронизировано с циклами разработки.
Итог
Ссылки
/